五、實際操作

Day 16 : 透過簡易的書店 API 來進行資料庫的版本控制
Day 17 : 透過 Entity Framework Core Migration 來進行資料庫的版本控制
Day 18 : 透過 Entity Framework Core Migration 對資料庫進行修改
Day 19 : 將 Entity Framework Core Migration 異動同步上 git
Day 20 : 將 Entity Framework Core Migration 流程套入 CI/CD 流程中
Day 21 : 透過 Entity Framework Core Migration 進行退版
Day 22 : 透過 Flyway 來進行資料庫的版本控制
Day 23 : 透過 Flyway 對資料庫進行修改
Day 24 : 透過 Flyway 異動同步上 git
Day 25 : 將 Flyway 套入 CI/CD 流程中
Day 26 : 透過 Flyway 進行退版
-> Day 27 : Entity Framework Core Migration vs Flyway

我們這幾天有介紹到了 Entity Framework Core Migration 與 Flyway 這兩款資料庫版本控制的工具，我們可以發現他們互有好處

Entity Framework Core Migration 的語言相依性高，他本身就是 .NET 框架中 ORM 的一項功能，因此會需要使用 .NET 體系來搭配使用，如果你的環境下有多個語言的 API 且有共用同一組資料庫就沒那麼適合

Flyway 幾乎沒有語言的相依性，但他更仰賴 SQL 與句的操作，部分功能也需要搭配 Java 或是付費版才能使用，如果團隊內有多個語言的服務在開發且有共用資料庫的需求時，可以考慮用 Flyway 來進行版控

總結來看，如果每個服務都獨立使用各自的資料庫，那使用 ORM 框架提供的 Migration 我認為會是一個對後端開發者掌控度較高的方案，也能以 ORM 框架的角度來限制資料庫的模型，反之如果團隊內較為多的技術取向與較多的共用資料庫，那使用 Flyway 會是更輕鬆的選擇

後續預告

下一篇我們將會講到比較特殊的情況，不同資料庫間的資料表遷移